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The NASA Autonomous precision Landing and Hazard Avoidance Technology (|ALHAT|) 
project developed a suite of prototype sensors to enable autonomous and safe precision land- 
ing of robotic or crewed vehicles under any terrain lighting conditions. Development of the 
lALHATl sensor suite was a cross-NASA effort, culminating in integration and testing on- 
board a variety of terrestrial vehicles toward infusion into future spaceflight applications. 
Terrestrial tests were conducted on specialized test gantries, moving trucks, helicopter 
flights, and a flight test onboard the NASA Morpheus free-flying, rocket-propulsive flight- 
test vehicle. To accomplish these tests, a tedious integration process was developed and fol- 
lowed, which included both command and telemetry interfacing, as well as sensor alignment 
and calibration verification to ensure valid test data to analyze ALHAT and Guidance, Nav- 
igation and Control (|GNC|) performance. This was especially true for the flight test cam- 
paign of lALHATl onboard Morpheus. For interfacing of lALHATl sensors to the Morpheus 
flight system, an adaptable command and telemetry architecture was developed to allow 
for the evolution of per-sensor Interface Control Design/Documents (jlCDk b Additionally, 
individual-sensor and on-vehicle verification testing was developed to ensure functional 
operation of the lALHATl sensors onboard the vehicle, as well as precision-measurement 
validity for each lALHATl sensor when integrated within the Morpheus IGNCI system. This 
paper provides some insight into the interface development and the integrated-systems 
verification that were a part of the build-up toward success of the lALHATl and Morpheus 
flight test campaigns in 2014. These campaigns provided valuable performance data that 
is refining the path toward spaceflight infusion of the lALHATl sensor suite. 

I. Introduction 

The NASA lALHATl project has developed and terrestrially flight tested a suite of prototype [GNC] tech- 
nologies (sensors and algorithms) applicable to crewed and robotic vehicles that enable autonomous and safe 
precision landing onto the lunar surface under any terrain lighting conditions. 1 2 3 The prototype sensor 
suite was tested in 2014 onboard the NASA Morpheus rocket-propulsive, terrestrial flight-test vehicle, or 
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Vertical TestBed (IVTBl) EEE1 Incorporating lALHATl capabilities onboard Morpheus or any IVTBl or space- 
flight vehicle requires a systems-level perspective throughout the design, implementation and testing cycle of 
both the components and the integrated system. The focus of this paper is on the systems-level interfacing 
and functional verification of the lALHATl sensors as both individual units and as components integrated 
into a vehicle IGNCI subsystem. This paper is a companion to another recent paper on the preparation and 
integration activities of the ALHAT sensors and Morpheus IGNCI leading up to the joint flight testing! 5 

The development of the ALHAT suite of capabilities has been through a multi-center collaboration within 
NASA, including NASA Johnson space Center (jJSCj), NASA Jet Propulsion Laboratory (|JPL[) . NASA 
Langley Research Center (jLaRCj), and many other supporting contractors and research centers, including 
the Charles Stark Draper Laboratory (jCSDL[) and the Johns Hopkins Applied Physics Laboratory (jAPL[) . 
The ALHAT sensors shown in Figure [l] include a three-beam Navigation Doppler Lidar (lNDL[) ^that provides 
precise velocity measurements, a long-range Lase r Alti meter (|LAlt[) ,^ and a flash Light detection And ranging 
(|Lidar[) -basecP Hazard Detection System (jHDSjl 10 Hi that provides real-time Hazard Detection (jHD[) 12 ! for 
onboard determination of safe landing sites. The Morpheus flight test performance of the individual sensors 
is highlighted in multiple recent papers (add SciTech citations). 



Figure 1. Prototype AL HAT sensors flight t ested o n Morpheus in 2014: long-range lLAltl (left), INDLl optics head and 
electronics (center), and IHDSI gimbaled flash [Lidarl (right). 


The Morpheus vehicle was designed as an autonomous VTB for accelerating the development and infusion 
of new technologies into spaceflight applications. For Entry, Descent and Landing ()EDL|) -related IGNCI 
technologies, IVTBk provide the capability to test and refine at the integrated-system level in dynamically- 
relevant, closed-loop operation prior to launch and actual mission lEDLl For IGNCI development. the Morpheus 
Flight Software (|FSW|) includes a dual-string Navigation (|Nav[) architecture (Ref Jake paper) with a baseline 
VTB Nav filter and an experimental (in this case ALHAT) Nav filter. As the prototype IGNCI technology 
matures from initial open-loop tests into fully closed-loop tests, the VTB Nav will continue to run as a backup 
in case the prototype IGNCI performs outside of specified tolerances. The nominal VTB INavl estimates 
vehicle state from onboard Global Positioning System (|GPS[) measurements, along Inertial Measurement 
Unit (lIMUj) measurements from a Space Integrated GPS/Inertial Navigation System (ISIGI)) sensor and 
altimetry measurements from an Acuity range sensor. The experimental INavl string is configured to execute 
I ALHATl Nav for the joint ALHAT/Morpheus flight testings, which utilizes only the ALHAT sensors and 
ISIGII for in-flight measurements. The in-flight monitoring of ALHAT Nav is performed by an Autonomous 
Flight Manager (|AFM[) running within Morpheus IFSWI 

The culmination of ALHAT field tests p^OAILLil along with the closed- loop testing of ALHAT onboard 
Morpheus has operationally demonstrated the ALHAT techniques and approaches in a relevant flight-like 
environment, which raises the ALHAT Technology Readiness Level dTRLll to 6 and prepares it for infusion 
into future spaceflight applications. The remainder of this paper will provide some insight into the abundance 
of stand-alone and integrated development and test activities that have been a part of the flight testing and 
ITRLI advancement for lALHATl Section [IT] will give a short overview of the flight trajectories flown onboard 
Morpheus. The internal interfacing of lALHATl systems and the interfacing of ALHAT with the Morpheus 
avionics is discussed within Section m This includes the definitions for data commanding and telemetry 
interfaces, as well as the architecture of sensor and vehicle time stamping. The testing and calibration 
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activities for ALH AT as a vehicle subsystem are discussed in Section |IV[ Section [V] provides an overview of 
the functional verification tests that were conducted for the fully integrated ALHAT/Morpheus in preparation 
for flight tests, and closing remarks are provided in Section [VT| 

II. Overview of Flight Profile 

Terrestrial flight testing of the ALHAT systems onboard Morpheus was conducted over a lunar-like terrain 
field constructed on the North end of the Shuttle Landing Facility (SLF) runway at Kennedy Space Center 
(|KSC[) . The Morpheus flight profile and the phases of operation for the ALHAT sensors used within the 
ALHAT [Navi filter during open-loop and closed-loop flight tests are illustrated in Figure [2j The flight profile 
is designed to put the vehicle in a dynamic state, following pitch over at peak altitude, that reproduces the 
conditions of a lunar approach for the Hazard Detection and Avoidance (IHDAj) phase of I ALHATl operation. 
The position and attitude of ALHAT Nav were initialized on the ground for the launch configuration, and 
during flight the only sensors providing measurement data to ALHAT Nav were the vehicle IIMUI and the 
three ALHAT sensors: LAlt, NDL and HDS. The LAlt provides altitude measurements to ALHAT Nav from 
10 meters altitude on ascent until ^25 meters altitude on terminal descent. The HDS operations commence 
at a slant range of 450 meters and continue through a slant range of 200 meters; these operations include a 
IHDAI and Hazard Relative Navigation (1HRN[) phase to generate the safe landing site and then provide site- 
relative position measurements, respectively. The IHDAl phase involves Digital Elevation Model/Map (|DEM[) 
generation followed by IHDI to determine the top safe landing site that the vehicle uses to conduct a hazard 
avoidance divert toward the safe location. The NDL provides velocimetry measurements following the 
completion of IHDSIDEMI generation until ^25 meters altitude on terminal descent. The HMUl remains active 
from takeoff through touchdown so that the final ~25 meters are ALHAT Nav dead reckoning on the IMU. 



Figure 2. Flight profile and ALHAT sensors operational timeline during open-loop and closed-loop flight testing on 
Morpheus. 


III. System Interfacing 

With the ALHAT and Morpheus team spread across multiple NASA centers, the coordination of interfaces 
and integration activities between the ALHAT components and the Morpheus avionics was implemented 
through the development and implementation of llCDk . The ICDs!s (ICDs!s) provides a set of specifications 
for interfacing not only mechanical hardware and electronics, but also provided guidelines for the different 
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system elements to develop internal timing architectures, develop software interfaces for commanding and 
telemetry, and create visual interfaces for test and flight operations. 

III. A. Mechanical and Electrical Interfaces 

The performance of ALHAT is driven by the accuracy and precision of the individual sensor measurements, 
the formulation of the algorithms within the ALHAT INavl filter to process the measurements, and the 
knowledge of sensor hardware integration onto the Morpheus vehicle. The sensors and Nav algorithms can 
be developed and tested stand-alone, but the integrated performance is heavily influenced by knowledge of the 
physical integration. The mechanical HCDk between ALHAT sensors and the Morpheus structural mounts 
included details on bolt patterns and torque specifications, along with provisions for alignment features, 
such as pin/slot combinations and alignment edges. These features provided mechanical means for repeated 
alignments; when components were mechanically mounted, they were clocked against the alignment features 
in the direction of bolt tightening, which minimizes re-mount alignment differences. 

The wiring and power interfaces were also outlined in lICDk that specified connector type, wire gauge, 
and intended purpose. All ALHAT intra-connect cables were developed, implemented and delivered from 
the ALHAT team, whereas all inter-connect cables between ALHAT and Morpheus components were co- 
developed. For the inter-connect cables, the ALHAT sensor provider assembled the core cable bundle and 
the connector on the sensor side; the vehicle side of the cable was left pigtailed with long-lead wires. The 
vehicle wiring team then terminated the ALHAT cables according to the HCDl once the ALHAT sensors were 
integrated onto the vehicle and the interface cables optimally routed base on accessibility and mass-reduction 
considerations. 

III.B. Managing Time 

Managing system time between the Morpheus VTB and the ALHAT sensors is critical for enabling precision 
landing capabilities. Relative timing errors between the vehicle time and the individual IGNCI sensor and 
ALHAT sensor times manifest as onboard Navigation errors in position, velocity and attitude. This in turn 
impacts onboard guidance algorithms that plan the descent profile to reach the desired safe landing site based 
on the knowledge provided from Navigation. The timing architecture within any synchronized system has 
two important attributes: 1) a reliable single source clock with reliable delivery method, and 2) an agreed 
upon interface to synchronize all other system endpoint clocks. The Morpheus VTB provides the central 
clock and delivery method to the ALHAT sensors, and a timing ITCDk specifies the synchronization method 
that is implemented between Morpheus and the ALHAT sensors. 

The timing precision necessary for the terrestrial testing of Morpheus and ALHAT could be achieved 
with a typical IGPSI timestamp and Pulse Per Second (jPPSD output provided from the Morpheus IGPSI 
receiver. The IPPSI signal occurs with each whole second rollover in IGPSI time. This time pulse provided 
the heartbeat for synchronizing the ALHAT sensors with Morpheus time. Distribution of the heartbeat can 
be accomplished by means as simple as using a splitter to distribute the clock rising edge or as complex 
as a digital phase relay with parallel processing and byzantine resilient voted output. The Morpheus VTB 
implemented the former method, being designed primarily as a zero fault tolerant system for simplicity and 
cost savings in developing the terrestrial testbed. 

For the Morpheus time initialization, the flight computer on initial boot up waits for a valid IGPSI times- 
tamp followed by three valid IPPSI pulses. Once received and checked for validity, the flight computer time 
is set to the GPS timestamp and then adjusted to the PPS whole second. The adjustment is essential in 
that the GPS timestamp in Morpheus occurs at 5Hz and is not guaranteed to arrive at a 1-second boundary. 
The PPS, however, is “guaranteed” to appear at the 1-second boundary. The clock corrects itself with each 
PPS signal arrival (sometimes forward, sometimes backward) with the adjustment typically made in the 
microsecond resolution. The adjustment is only only allowable within a small window around the 1-second 
threshold to protect against any stray signal on the wire (e.g., Electro-Magnetic Interference (jEMI[B being 
interpreted as the IPPSl signal. 
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The time HCDl between Morpheus and ALHAT requires the delivery of a IPPSI heartbeat that is immedi- 
ately followed (prior to the next IPPS [) by a separate ethernet packet containing the Morpheus vehicle time 
defined in “seconds since epoch” of a pre-defined epoch. The ALHAT sensors synchronize to Morpheus 
vehicle time by latching whole seconds to the IPPSI The handling of sub-seconds is done internally to each 
of the ALHAT sensors with slight implementation variations, but effectively the IPPSI arrival signals a roll 
over to the next whole second. 

The HDS in particular has a further layer of complexity with time handling. The HDS generation of 
safe landing sites during [HD] and site-relative position measurements during IHRNI requires the generation of 
a seamless IDEMI and knowledge of image times relative to the Morpheus Nav state. This process requires 
the real-time fusion of multiple, asynchronous sensors internal to the HDS. To enable this fusion, the HDS 
Compute Element (jHDSCEj) design incorporates a Field Programmable Gate Array (|FPGA[) for internal 
time management, to aggregate all Input /Output ( |I/Q ) data, and to annotate the |I/Q| data with a system 
time associated with a measurement event from each internal sensor. 16 This implementation both reduces 
|I/Q| requirements and eliminates tight real-time Operating System requirements for the IHDSCEI processor. 
Additionally, having a single central system clock within the IHDSI avoids the need to manage different 
time interpretations across the many different internal-HDS sensors (gimbal, IIMUI ILidar[) . Each of these 
internal devices provide a discrete event signal flag that indicates to the IFPGAI when the device is taking a 
measurement. When data for that device flows through the lFPGAl its data packet gets annotated with the 
contents of the “event time” register and passed to the IHDSCEI processor for use in IDEMI generation, IHDI 
or IHRNI processing. 


III.C. Software Interfaces: Commanding and Telemetry 

The Morpheus and lALHATI teams were distributed across multiple NASA centers, and individual components 
were developed seperately and not physically connected until very late in the design cycle. This made 
defining the IICDI between the various components critical, as there would be limited time available for 
debugging/troubleshooting. To ensure all the components would talk with each other (and minimize schedule 
impacts from any integration troubleshooting ) we developed a software ICD for each of the I ALH ATI sensors 
(iNDl^CAiproa and the Morpheus Flight computer (Avionics and Power Unit (1APU[P . Once adopted, 
these HCDl s were only changed after agreement from all teams. So each team knew exactly what to send and 
receive from the others, and ths enabled interface checkouts prior to completion of the other components. 

After obtaining consensus on the commands/telemetry in the HCDl the team then deployed a ” software 
emulator” that could send an arbitrary data message to/from each sensor and Morpheus. These telemetry 
emulators were invaluable in ensuring that the Morpheus vehicle could send/receive messages to the sensors 
and helped catch interface issues (such as byte ordering, structure alignment, bit packing) prior to physical 
hardware integration. As a result we had a smooth SW interface integration every time the units were 
connected. The one thing that these emulators did not accurately replicate the precise timing of when 
messages would be sent; as noted in Section [V| these subtle timing variations caused some software issues 
that were not identified/addressed until integrated functional checkout. 

The downlink telemetry link represented less than 2% of the data produced by Morpheus, which was 
logged onboard the vehicle. In contrast to the high bandwith data pipes available during the development 
process, once the vehicle was flying, the narrow (5KByte/second) telemetry link on Morpheus forced careful 
selection of which items to downlink. Selecting which parameters would be included in the downlink stream 
was a constant battle throughout the development process. This struggle required subsystem negotiation, 
and even resulted in a friendly contest (free dinner) to see which subsystem could reduce their bandwidth 
the most. 

Once a set of parameters to downlink was agreed to, Morpheus utilized a ”copy table” to set up a series 
of memory copies to extract the specified memory locations from various SW modules to produce a unified 
downlink message stream. This ”copy table” needed to be synchronized with any ICD change of any onboard 
software modules. In addition, as the ground displays evolved, and operators needed to have access to new 
data items (or any increase/decrease the rate an item was sent) the copy table needed to be changed. And 
each new copy table needed to be verified to ensure it was error free and in sync with the ground software so 
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it would be decoded correctly. Generation of the copy table was initially done by hand, but it was quickly 
apparent that as we needed an automated process to make verification of the synchronization a feasible task 
since even a minuscule change to the flight SW (say 1 additional byte of status data) could trigger hundreds 
of changes in the copy table, and would take hours of time to do (and verify) by hand! 

Eventually, the Command And Data Dictionary (ICDDj) for Morpheus was established as the authoritative 
version control system for the ’’copy table” and Integrated Test and Operations System (IITOS|) rec files. The 
ICDDI also contained the limits (high and low) for parameter values, downlink frequency, and the calibration 
values for each parameter. After building a second IAPUI it became apparent that the analog channels on 
the two systems were calibrated differently enough that separate sets of calibration constants was needed 
for to each IAPUI The correct constants were obtained by specifying which IAPUI was being targeted when 
running the ICDDI auto-generation software toolchain. 
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Figure 3. Command and Telemetry path for Morpheus \ ALH ATI 


III.D. Operations Interfaces 


IITOSI was used to perform all monitoring and control of the Morpheus vehicle while in flight. 17 IITOSI was 
developed by Goddard Space Flight Center (|GSFC[) to communicate with space vehicles using Core Flight 
Software (which is the software used in Morpheus) . Since the IALHATI sensors data was integrated into the 
vehicle telemetry (See Section III.C), the Morpheus data link contained ALHAT telemetry. The single data 
path to the Morpheus vehicle was connected to a ’’headless” interface computer, whose sole job was to relay 
to data from the control room to the vehicle. (See Figure [3]). 

Because all of the data from the vehicle was sent via multicast to the control room, each computer had 
equal access to all the telemetry, and could bring up any page/plot in IITOSI The single multicast of the 
data eliminated the need for a separate transmission to each of the computers in the control room: the 
same amount of work was done by the Interface Computer if there were 1 or 100 computers consuming the 
telemetry. This multicast data was also “reflected” to IJPLJ/lJSC|/1LaRCl so that IITOSI data could be viewed 
remotely in real time across the country by team members who were not physically present at IKS Cl for a test. 
Each console position would generally be monitoring only the IITOSI pages/ plots that were relevant to them 
during the tests. In fact, most of the pages for the various console positions were built by the subsystems, 
allowing them to see exactly the data they wanted. 

Only a single station could send commands to the Morpheus vehicle. This was done partly to avoid 
command contention issues that could arise from allowing multiple computers to send commands, and also 
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because the command processor in IITOSI consumed a fair amount of CPU resources, and the computers 
were more responsive when it was not running. Any station could bring up the command pages, and “push” 
a command buttons, but no commands would be sent unless they originated from the Operator console 
station. This helped reduce the chance of issuing a command accidentally, since all commands would be 
ignored from most computers in the control room. A few examples of the hundreds of pages/plots developed 
for Morpheus / I ALH ATI can be see in Figure [4] 



IV. lALHATl Testing prior to Morpheus Vehicle Integration 

The flight performance of ALHAT onboard Morpheus is driven by both the stand-alone ALHAT sensor 
performance and the integrated performance of ALHAT with the Morpheus IGNCI subsystem. Prior to the 
flight testing at KSC, the ALHAT project conducted multiple, stand-alone field and calibration tests JlHLiHEH 
along with several joint tests with Morpheus avionic^ 11 13 14 and flight simulations. These tests were impor- 
tant for the development and refinement of ALHAT technologies, as well as for risk mitigation leading up 
to the flight testing on Morpheus. This section highlights some of the calibration activities, as well as field 
testing and simulations conducted while maturing ALHAT and preparing it for the Morpheus flight tests. 

The NDL sensor provides three individual Line of Sight (|LOS[) velocity measurements that are used to 
resolve the Morpheus velocity vector. Calibration of the ILQSI measurements for each beam, along with 
knowledge of each beam direction relative to the NDL mechanical assembly is essential for resolving the 
spacecraft velocity vector in the body frame. The beam calibrations were established by comparing LOS 
measurements with independently measured motion of a high-fidelity and very-low-distortion sub-woofer 
driven at low frequency. The alignment knowledge for each beam was established through metrology mea- 
surements shown in Figure [5] of point targets along each beam LOS relative to fiducial locations on the 
mechanical base onto which each telescope attaches. 

The IHDSl in-flight performance depends on how well the sensor can point the flash-Lidar optical boresight 
vector to obtain the desired terrain images for HD and HRN. The pointing performance is affected by 
component-to-component alignment and calibration knowledge within the HDS, as well as the accuracy 
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Figure 5. Metrology measurements of NDL Line-of-Sight beams relative to mechanical mounting fixture. 


of the ALHAT Nav estimate that HDS uses for pointing toward a desired terrain region. To establish 
internal component- wise alignment, a laser metrology system was used to resolve the FL boresight vector 
relative to the FL mechanical mount, the FL mechanical mount relative to the inner gimbal rotation axis, 
the rotation vectors for both gimbal axes, and the gimbal mount relative to the HDS IMU. Additionally, 
long-distance range calibrations were performed to determine the accuracy and precision of the FL sensing, 
and 19-bit encoders were used for measuring gimbal pointing angles to minize error. To improve further on 
the component-wise alignment and calibration, an end-to-end pointing test to multiple distant targets (also 
measured with metrology) was performed, and the offset errors were averaged to provide a final end-to-end 
correction for systematic bias. The end result is a stand-alone HDS with pointing knowledge to within 0.05° 
of the commanded target. For further information on the HDS alignment and calibration processes, along 
with details on general HDS operations or other field testing, refer to the references E 3E1 

Alignment of the HDS to ALHAT Nav is of critical importance for HD and HRN during flight tests. 
To assemble the DEM for HD, the HDS gimbal slews the FL to collect a mosaic of terrain images that 
are seamlessly fused together in software. To avoid the potential for holes in the DEM, the HDS does not 
accept Nav updates during mosaicking but instead propagates the Nav solution with the dedicated HDS 
IMU. To minimize pointing error growth during this propagation, the relative attitude between the HDS 
IMU and the Morpheus SIGI was obtained through analysis of long-dwell data collected in multiple vehicle 
tilt configurations (Figure [6]). 



Figure 6. Tilt tests of integrated Morpheus vehicle with [ALHATl Hazard Detection System to compare gyro orientations 
with metrology measurements. 


The HDS Flash Lidar (jFLj ) has a narrow 1° Field of View (|FOV[) lens, which was chosen so that the 
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HDS could created 10-cm resolution IDEMk from up to a 1-kilometer range. The narrow IFQVI provides 
some challenges in situational awareness when post processing the iFLl data to resolve pointing errors or 
data ambiguities. For this reason, an optical witness camera was mounted under the IFLl sensor head and 
co-aligned with the IFLl boresight (Figure [7]) to provide a larger IFQVI image (8° along the diagonal). The 
witness camera is aligned to the HDS IFLl bv pointing the HDS to two distant targets and assessing the relative 
parallax between the IFLl and witness camera images. The same two targets are also used for assessing INavl 
initialization that will be discussed in Section El 


Optical Witness Camera 



Figure 7. An optical witness camera with larger IFQVI that the HDS IFLl provides additional situational awareness in 
post-flight data analysis and in pre-flight checkouts. 


Early functional interfacing and integrated testing between ALHAT and Morpheus avionics (primary 
flight computer and SIGI) were conducted in labs and in two field tests. The lab tests were primarily for 
interfacing components and were dubbed FlatSat testing since the avionics and sensors were tested on a 
flat bench. The field testing was conducted on two dynamic platforms, a truck and a hehcopteJmEMSH as 
seen in Figure [8] These field tests were valuable for the development and functional testing of the ALHAT 
sensors interfaced with the Morpheus avionics and provided risk reduction for the joint free flight testing 
on the Morpheus VTB. The truck testing was conducted at the ILaRCl Long Distance Test Range (|LDTR[h 
which is of an 800+ meter test track with a target wall on one end. The ALHAT sensors and electronics 
were located within the cargo area of the truck as seen in figure. The HDS and LAlt had a forward view 
through a window in the front of the cargo hold, and the NDL was cantilevered off the rear of the truck with 
a ground view. The target was configured with hemispherical targets to allow functional testing of HDS 
DEM generation and HD algorithms, as well as pointing operations on the ALHAT Nav. The helicopter 
flight tests were conducted KSC over a lunar-like terrain field constructed for the Morpheus VTB flight test 
and provided the closest possible ALHAT operational data prior to the actual free flights on Morpheus. 

Truck Testing Helicopter Testing 



Figure 8. Joint field tests were conducted with ALHAT and Morpheus avionics on a truck (left) and helicopter (right) 
in preparation for free flight tests on the Morpheus vehicle. 



In additional to early interfacing testing, simulations were used to understand and refine the Concept of 
Operations flConOpsI and integrated performance of ALHAT on Morpheus prior to integration and flight 
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testing with the actual systems. The team conducted extensive testing using NASA’s Trick 2( 3 simulation tool 
that runs the full Morpheus IFSWI set. The Trick simulation framework (developed by NASA/ TTSC]) provides 
a full 6-DOF environmental simulation, and is currently in use by a wide range NASA projects. In addition 
to using the flight software, Trick requires a model for each sensor, as well as a models for each actuator 
that can be controlled by the vehicle. The simulator sensor models construct measurements based on the 
simulated translation and rotation state of the vehicle. These measurements are fed into the IFSWi which 
processes the them and decides what commands to send to the actuators. Trick then evaluates the actuator 
models and calculates the next state of the vehicle (and then starts the loop again). The benefit to using this 
framework is to determine what the flight code would do in response to given stimulus without risking the 
vehicle, as well as to allow running Monte Carlo simulations to see how sensitive the outputs are to various 
parameters. 

V. Functional Verification onboard Morpheus for Flight Tests 

Functional verification of the ALHAT sensors with the Morpheus IGNCI and Avionics subsystems was 
necessary following integration of ALHAT onto Morpheus. The verifications initially included whole- system 
power up and command/telemetry checks between the Morpheus flight operations displays and the ALHAT 
sensors. More focused tests looked at the individual ALHAT sensor measurements to verify good time 
synchronization and proper incorporation of alignment information for Nav processing of the measurements. 
The verifications concluded with tether testing of the fully integrated vehicle prior to free flights, followed 
by health and status checks of the ALHAT sensors in between flights. 

A functional verification of ALHAT Nav integration with the LAlt and NDL was performed through a 
swing test of the entire Morpheus vehicle suspended on a crane, as shown in Figure [9j The low altitude and 
oscillation rate of the swing test put the NDL in a mode of operation outside of the design implementation, 
which precluded precision Navigation testing, but nonetheless, the test provide a desired functional verifica- 
tion of good time synchronization and proper incorporation of metrology alignment transforms. Comparison 
of the VTB Nav (based on GPS, SIGI and Acuity measurements) estimates for velocity with the direct NDL 
measurements of velocity verified alignment transforms. The comparisons also revealed any time lags due to 
system initialization or unresolved integration bugs. The lifting and lowering of the vehicle for the swing test 
also allowed direct comparisons between the Acuity range measurement and the LAlt measurements, which 
were used for basic calibration checks. Initial swing tests revealed a polarity flip in how ALHAT Nav handled 
the NDL ILQSI velocity measurements and also helped the ALHAT and Morpheus teams refine operational 
procedures for flight testing. 



Figure 9. Swing tests of integrated Morpheus vehicle with [ALHATl Navigation Doppler Lidar and Laser Altimeter. 
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Throughout the campaigns, the HDS IFLI pixels were monitored for degradation because the prototype 
sensor is not hermetically sealed. Pixel damage can be caused from adverse environmental conditions (mainly 
conditions of either high relative humidity or dew point temperatures near the focal plane array’s operating 
temperature) or focal plane array age. In between flights and during all pre-flight operations, the FL is 
purged with dry air to minimize humidity- and dew point-related damage. An in-flight purge was not in 
place for early flights, so pixel damage was assessed between flights. Intermittent, damaged pixels generally 
produce range solutions between zero meters and range values within one to two meters of the actual range 
value of the surrounding pixels, which makes them them difficult to filter. The damaged pixels can cause 
holes or spikes in the DEM that are interpreted as hazards, especially if the damaged pixels cluster together. 
If the bad pixels are known prior to flight, the problematic regions can be masked out in the process of DEM 
generation. Prior to each flight, on-ground testing was conducted to determine if the Flash Lidar?s pixel 
mask needed to be expanded to cover any new intermittent pixels. The on-ground testing involves imaging a 
flat target board at a near zero degree angle of incidence so that all of the 16,384 pixels should produce the 
same range solution within the precision limit of the sensor. Any pixels which produce range values outside 
the precision limit are flagged as intermittent pixels and are added to the pixel mask which assigns a range 
value of zero to them so that they can be easily filtered from the range image during real-time processing. 
Figure [lO] shows a pixel mask test. In the test, the IFLI median filter has been temporarily deactivated so 
that individually masked pixels are visible and display zero range. Several new intermittent pixels are also 
visible; they produce range values approximately 1 meter in error and need to be added to the iFLl pixel 
mask. 
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Figure 10. Flash Lidar pixel mask test (with median filter temporarily deactivated) from 5/20/2014 in which the flat 
GIDE target board is imaged at approximately a zero degree incidence revealing currently masked pixels with zero 
range and intermittent pixels which need to be added to the mask. 


The tight coupling of HDS performance with the onboard INavl accuracy drove the inclusion of a ground- 
based HDS pointing test to verify Nav initialization prior to every flight test. The operational design for 
HDS requires combined pointing knowledge error between HDS and Nav to be less than 0.25°. The onboard 
VTB and ALHAT Nav states are initialized on the ground through a process of gyrocompassing and roll 
alignment to determine the initial inertial position and attitude of the vehicle; an optical sextant mounted 
on the vehicle is used to measure angular offsets to a known, surveyed ground target and determine roll 
(yaw in aircraft convention) corrections to improve on the gyrocompassed attitude solution. Following Nav 
initialization, the HDS is commanded to point the IFLl at two GPS-surveyed ground targets (Figure [IT] ) 
at approximately 88 and 349 meter ranges. The full FL range image is not sent through telemetry to the 
Morpheus mission control center due to vehicle communications bandwidth limitations, but an average range 
for the central nine pixels is transmitted, along with an optical image from the witness camera discussed in 
Section |IV[ The witness camera image is observed in the control room, along with the range reported from 
the FL telemetry data, to assess whether or not the initial Nav solution provides the accuracy required for 
pointing HDS. 

The final full- up functional checkout prior to free flight testing is a tether test (Figure [l2| of the ALHAT 
systems onboard Morpheus. After every major change to the vehicle, or after extended downtime, the team 
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Figure 11. HDS pointing to near (left) and far (right) surveyed targets based on Nav initialization: Co-boresighted 
witness camera images and FL range images are shown. 


performed a tethered flight test to verify function and operation. For the ALHAT sensors, the tethered flights 
are primarily a test of in-flight function rather that an opportunity to collect valid data for performance 
analysis. The low altitude and minimal surface-relative speeds limit the valid data coming from the ILAltl 
and INDL1 Additionally, the shallow viewing angle and short range to the ground causes the HDS FL to 
de-focus and not provide valid terrain images. Nonetheless, the tethered flights provide and opportunity for 
integrated functional opperation between ALHAT and the IGNCl subsystem. Early tethered flights were used 
for initial verification of dynamically pointing the HDS from the onboard INavl state. These tests helped to 
identify time lags within the system between the Nav state sent to the HDS and the higher-rate HDS IMU. 



Figure 12. Tether flight of ALHAT sensors in preparation for free flight testing. 


VI. Closing Remarks 

The successful integrated performance of the ALHAT sensors onboard Morpheus during the 2014 joint 
flight testing was made possible through the systems engineering of the ALHAT sensors, the Morpheus 
vehicle, and the collaborative approach to integration and testing. The detailed development, calibration and 
testing of the stand-alone ALHAT sensors provided known precision and accuracy during sensor operation. 
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The use of well-defined interfaces between the sensors and vehicle, along with the detailed integration testing 
and follow-ion functional verifications provided confidence that the ALHAT and Morpheus systems would 
perform as desired in free flight tests. The free flight tests in 2014 were highly successful, providing a wealth 
of data for analyzing and refining ALHAT sensors performance and for raising the overall ITRL I of the ALHAT 
systems to a 6, preparing it for infusion into future spaceflight applications. 

List of Acronyms 


AFM 

Autonomous Flight Manager 

ALHAT 

Autonomous precision Landing and Hazard 
Avoidance Technology 

APL 

Johns Hopkins Applied Physics Laboratory 

APU 

Avionics and Power Unit 

CDD 

Command And Data Dictionary 

ConOps 

Concept of Operations 

CSDL 

Charles Stark Draper Laboratory 

DEM 

Digital Elevation Model/Map 

EDL 

Entry, Descent and Landing 

EMI 

Electro-Magnetic Interference 

FL 

Flash Lidar 

FOV 

Field of View 

FPGA 

Field Programmable Gate Array 

FSW 

Flight Software 

GNC 

Guidance, Navigation and Control 

GPS 

Global Positioning System 

GSFC 

Goddard Space Flight Center 

HD 

Hazard Detection 

HDA 

Hazard Detection and Avoidance 

HDS 

Hazard Detection System 


HDSCE HDS Compute Element 

HRN Hazard Relative Navigation 

ICD Interface Control Design/Document 

ITOS Integrated Test and Operations System 

I / O Input / Output 

IMU Inertial Measurement Unit 

JPL Jet Propulsion Laboratory 

JSC Johnson space Center 

KSC Kennedy Space Center 

LAIt Laser Altimeter 

LaRC Langley Research Center 

LDTR Long Distance Test Range 

Lidar Light detection And ranging 

LOS Line of Sight 

Nav Navigation 

NDL Navigation Doppler Lidar 

PPS Pulse Per Second 

SIGI Space Integrated GPS/Inertial Navigation 

System 

TRL Technology Readiness Level 

VTB Vertical TestBed 
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